Summary

Add declarative bind blocks under a target so users can bring existing
workspace resources under bundle management at deploy time without
manually running bundle deployment bind. Direct engine only — bind
blocks under the terraform engine, in bundle deployment migrate, or
under bundle destroy (when the bind matches a resource currently in
state) all surface actionable errors.

targets:
  default:
    bind:
      jobs:
        my_job:
          id: "12345"

Two new actions show up in bundle plan:

• bind — resource is imported, no field changes
• bind_and_update — resource is imported, drift is applied

Design

• Bind config type and bind field on Target in bundle/config,
  plus a structural validator that rejects child resources
  (*.permissions, *.grants).
• Bind logic is isolated in bundle/direct/bundle_plan_bind.go —
  DeploymentBundle.ApplyBindToPlan runs after CalculatePlan,
  validates references, detects ID conflicts, reads remote state, and
  selects Bind vs BindAndUpdate per resource. CalculatePlan itself
  is unchanged.
• DeploymentUnit.DeclarativeBind apply path persists the bound ID
  (and invokes DoUpdate for BindAndUpdate).
• Targeted error in libs/dyn/convert/normalize.go for bind placed at
  the root level (otherwise it would silently degrade to an "unknown
  field" warning).

Test plan

Acceptance coverage in acceptance/bundle/deploy/bind/:

• Happy path: basic, bind-and-update
• Validation errors: invalid-resource-type, orphaned-bind,
  top-level-bind, duplicate-bind-id, terraform-with-bind,
  bind-permissions
• Runtime errors: resource-not-found, recreate-blocked
• Lifecycle guards: block-migrate, destroy-blocked,
  delete-and-bind-conflict

Unit tests for bundle/config/bind.go,
bundle/config/mutator/validate_bind_resources.go, and the new
normalize-time error in libs/dyn/convert/normalize.go.

This pull request and its description were written by Isaac.